fix(cli): fail loudly when turso/libSQL is selected in the open-core CLI (#3276 follow-up) - #3292
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
github-actions
Bot
added
documentation
Contributor
📓 Docs Drift CheckThis PR changes 1 package(s): 17 hand-written doc(s) reference the affected code and may need an implementation-accuracy re-verification:
|
xuyushun441-sys
force-pushed
the
fix/cli-memory-driver-dispatch
branch
from
July 19, 2026 16:10
e157e0c to
d8cfa0b
Compare
xuyushun441-sys
force-pushed
the
fix/cli-turso-loud-error
branch
from
July 19, 2026 16:11
06550d7 to
728757e
Compare
…CLI (#3276 follow-up) Same "declared ≠ enforced" bug class as the `memory` fix (#3276): `os dev` / `os start` / `os serve` advertise a `turso` driver (`--database-driver turso`, `OS_DATABASE_DRIVER=turso`, `libsql://` URLs), but the dispatch had no `turso` branch — so selecting it silently fell through to the SQLite default and ignored the requested remote libSQL connection. turso/libSQL is a cloud/EE driver (`@objectstack/driver-turso`, an extension of SqlDriver over `@libsql/client`), composed by the cloud runtime's own kernel factory; the open-core standalone stack deliberately stopped consuming it and its config schema lives in the cloud package to keep it out of `@objectstack/spec`. Rather than pull the EE driver into open-core: - `createStorageDriver` throws a typed `UnsupportedDriverError` for `turso` / `libsql`, with an actionable message (names @objectstack/driver-turso + the open-core alternatives). - `serve.ts` re-throws it from the driver block's catch so run()'s fatal handler prints the message and exits 1 (dev AND prod) — never a silent SQLite boot. - `inferDriverTypeFromUrl` keeps classifying `libsql://` / `*.turso.*` as `turso` (not '') so those URLs hit the same loud failure instead of the SQLite default. Verified end-to-end: `OS_DATABASE_DRIVER=turso` and `OS_DATABASE_URL=libsql://...` both exit 1 with the fatal message; `OS_DATABASE_DRIVER=memory` still boots. Unit tests prove the branch goes red (dev→SqlDriver, prod→null) without it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
xuyushun441-sys
force-pushed
the
fix/cli-turso-loud-error
branch
from
July 19, 2026 16:21
728757e to
977c2fe
Compare
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The same "declared ≠ enforced" bug as #3276, for
turso/libSQL:os dev(dev.ts:89) andos start(start.ts:100) advertisetursoas a--database-driveroption, andlibsql://URLs in help/examples.inferDriverTypeFromUrlmapslibsql://and*.turso.*URLs to driver kindturso.tursobranch — so selecting it (viaOS_DATABASE_DRIVER=turso,--database-driver turso, or alibsql://URL) silently fell through to the SQLite default and ignored the requested remote libSQL connection.Why not just "add a turso driver" (option a)
Investigated:
@objectstack/driver-tursois a cloud / EE package (../cloud/packages/driver-turso) — it extendsSqlDriverover@libsql/client, is composed by the cloud runtime's own kernel factory (cloud-stack.ts/environment-kernel-factory.tsdonew TursoDriver({ url, authToken })), and its spec schema lives in the cloud package specifically to keep it out of open-core@objectstack/spec.runtime/standalone-stack.tsexplicitly stopped consuming its auth token. So turso is deliberately not an open-core engine — pulling it into open-core's dispatch would reintroduce the coupling the architecture removed.Fix (option b, refined — recognize + fail loud)
createStorageDriverthrows a typedUnsupportedDriverErrorforturso/libsql, with an actionable message (names@objectstack/driver-turso, explains cloud/EE vs. explicit config, lists the open-core alternatives).serve.tsre-throws it from the driver block's catch sorun()'s existing fatal handler restores output, prints the message, and exits 1 (dev AND prod) — never a silent SQLite boot.inferDriverTypeFromUrlkeeps classifyinglibsql:///*.turso.*asturso(not''), so those URLs hit the same loud failure instead of the SQLite fall-through.dev.ts/start.tschanges: turso is a real driver in the cloud distribution (which reuses these commands and documentsOS_DATABASE_DRIVER=turso), so the honest fix is a clear error — not un-advertising it.Verification
os serveon the host-config path):OS_DATABASE_DRIVER=tursoandOS_DATABASE_URL=libsql://my-db.turso.ioboth exit 1 with the fatal message; controlOS_DATABASE_DRIVER=memorystill boots.storage-driver.test.ts) prove the branch goes red without it (dev→SqlDriver, prod→null) and assert the message is actionable. 18/18 in-file; 41/41 across serve/dev/storage suites.tsc -p tsconfig.build.json+eslintclean.🤖 Generated with Claude Code